All committers have signed the CLA.

An overall comment. The V1 primitives usage was deprecated in 0.8 release and marked for removal in 0.9. So in that regards that aspect of this PR fits with the plan as the next main release to happen would be 0.9. However the removal of the Blueprint circuit support - this was deprecated in this PR #945 which was intended to go out in 0.9 with the removal in a subsequent version. Qiskit has deprecated these Blueprint based circuits with the plan to remove them in 0.3 3.0. So they do not need removing to support 0.2 2.0 indeed removing them, without even having released 0.9 with them being deprecated (as done in #945) would be a breaking change for end-users with no notice at all. Hence that aspect of this PR is really too soon.

So they do not need removing to support 0.2 indeed removing them, without even having released 0.9 with them being deprecated (as done in #945) would be a breaking change for end-users with no notice at all. Hence that aspect of this PR is really too soon.

Hi, do you mean that since BlueprintCircuit is just deprecated in the 2.1 and will be removed completely in 3.0, we should not remove it or its related components? Like ZZFeatureMap and RealAmplitudes?

Hi, do you mean that since BlueprintCircuit is just deprecated in the 2.1 and will be removed completely in 3.0, we should not remove it or its related components? Like ZZFeatureMap and RealAmplitudes?

Yes they were deprecated in Qiskit 2.0 and planned to be removed in 3.0 (my bad I typed 0.2 and 0.3 above - I edited the original comment. As ML has not been released with the update that deprecates their use itself we do not want to remove Blueprint circuits from being used at this time - rather in a future version to allow users to change/update any existing code they may have that uses these rather than it just breaking if their support was removed. The next version of ML to be released, i.e. 0.9, would include their deprecation as was added by #945. So far that code only exists here in the repo until such time as a new release is made that includes it in the official version (i.e 0,9). Is that clearer. Removing the V1 primitive support is ok, V2 support was added in the last release (0,8) so both were supported by ML but V1 usage was deprecated - giving time for people to switch their code to V2. So the plan was to remove V1 support for the 0.9 release. So you see the pattern, support both old way, but deprecated, and the new way for a period of time to allow users time to changeover without breaking their code,

As ML has not been released with the update that deprecates their use itself we do not want to remove Blueprint circuits from being used at this time - rather in a future version to allow users to change/update any existing code they may have that uses these rather than it just breaking if their support was removed.

I agree, we don't want to break the user experience for the users. But what I am trying to say is that even if we remove these, it won't break the user experience. Let's take one example, the function utils.adjust_num_qubits.derive_num_qubits_feature_map_ansatz takes in num_qubits, feature_map, ansatz and use_methods as parameters. I have simplified the logic by removing the use_methods and usage of BlueCircuit derived classes. But I have not removed BlueCircuit usage completely. The QNNCircuit class still exists and I have not made any change to that. So, I think the changes I have made regarding that do not impact the user experience and the code. However, I would like to hear your thoughts on this as well.

Hey @woodsp-ibm , is there any blocking issue?

Overall lgtm. However, some test cases needs to be cleaned up before 0.9.

I think it is ready when the errors are fixed for the unittests.

Thanks for quite the fixup. I guess QCA removed quite a lot of copyright comments. Anyways, I'll start working on the test cases which are failing

A recurring error so far is the following:

circuit_key = hash(circuit)
                  ^^^^^^^^^^^^^
TypeError: unhashable type: 'QuantumCircuit'

with qiskit==2.1.2

And also clashed between Class and Method definitions of circuits (cfr BlueprintCircuit):

  File "/qiskit-machine-learning-Siddharthgolecha/test/circuit/library/test_qnn_circuit.py", line 97, in test_construction_before_build

AssertionError: <class 'qiskit.circuit.quantumcircuit.QuantumCircuit'> != <function zz_feature_map at 0x107740400>

Also the Readme example seems to need tweaking...
test_readme_sample.py", line 78, in test_readme_sample
self.assertGreater(score, 0.7)
AssertionError: 0.5 not greater than 0.7